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(1) Real Party in Interest 

The real party in interest is Microsoft Corporation, the assignee of all right, 
title and interest in and to the subject invention. 

(2) Related Appeals and Interferences 

Appellant is not aware of any other appeals, interferences, or judicial 
proceedings that will directly affect, be directly affected by, or otherwise have a 
bearing on the Board's decision to this pending appeal. 

(3) Status of Claims 

Claims 1-29 stand rejected and are pending in this Application. The 
rejections of Claims 1-29 are appealed. Claims 2-7, 9-10, 13-14, 16-21, 23-26, 
and 28-29 are original and hence bear the designator "(original)". Claims 1,8, 11- 
12, 15, 22, and 27 are previously presented and hence bear the designator 
"(previously presented)". 

Claims 1--29 are set forth in the Appendix of Appealed Claims on page 29. 

(4) Status of Amendments 

The Final Office Action, which is the subject of this Appeal, was mailed 
May 20'^ 2004 (herein the "Final Office Action"). 

The Office mailed an Advisory Action on October 5^, 2004, after which 
Appellant filed a Notice of Appeal dated November 19^, 2004. 

No amendments were made to the claims subsequent to the final rejection. 
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(5) Summary of Claimed Subject Matter 

A concise explanation of each of the independent claims is included in this 
Summary section, including specific reference characters. These specific 
reference characters are examples of particular elements of the drawings for 
certain claimed embodiments. It is to be appreciated and understood that the 
claims are not to be limited to solely the elements corresponding to these reference 
characters and that this section is provided to comply with the requirement of 37 
CFR§41.37(c)(l)(v). 

Claim 1 recites a method for use in a computer (20), the method 
comprising, while booting a computer ("start" of Fig. 3 and 202) and prior to 
allowing a user to logon (214) to the computer (20), arranging for a markup 
language rendering engine (page 8, lines 3-8) to be loaded (204) substantially near 
the beginning ("start'' of Fig. 3 and 202) of an operating system initialization 
procedure (see 202); and providing (206) markup language code (page 9, lines 8- 
13 and page 10, lines 1-17) suitable for use with the markup language rendering 
engine (page 8, lines 3-8), the markup language (page 9, lines 8-13 and page 10, 
lines 1-17) being capable of soliciting (208) at least one user input when rendered 
(104, 110, and 1 12) by the markup language rendering engine (page 8, lines 3-8), 
the user input being associated with a user logon process (210, 212, and 214) 
configured to selectively allow (214) a user to logon to the computer (20). 

Claim 8 recites a computer-readable medium (36) having computer- 
executable instructions for causing one or more processors (21) to perform acts 
comprising, while booting a computer ("start" of Fig. 3 and 202) and prior to 
allowing a user to logon (214) to the computer (20), arranging for a markup 
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language rendering engine (page 8, lines 3-8) to be loaded (204) substantially near 
the beginning (^'start'' of Fig. 3 and 202) of an operating system initialization 
procedure (see 202); and providing (206) markup language code (page 9, lines 8- 
13 and page 10, lines 1-17) suitable for use with the markup language rendering 
engine (page 8, lines 3-8), the markup language (page 9, lines 8-13 and page 10, 
lines 1-17) being capable of soliciting (208) at least one user input when rendered 
(104, 1 10, and 1 12) by the markup language rendering engine (page 8, lines 3-8), 
the user input being associated with a user logon process (210, 212, and 214) 
configured to selectively allow (214) a user to logon to the computer (20). 

Claim 15 recites an arrangement including a memory (22), a data storage 
device (27 or 50), a display device (47), and a processor (21) operatively coupled 
(23) to the memory (22), data storage device (27 or 50) and the display device 
(47), the arrangement comprising a markup language rendering engine (page 8, 
lines 3-8) stored within the data storage device (27 or 50) and suitable for loading 
in the memory (22) substantially near the beginning ("start" of Fig. 3 and 202) of 
an operating system initialization procedure (see 202) while booting a computer 
(20) and prior to allowing a user to logon (see 214) to the computer (20), and 
markup language code (page 9, lines 8-13 and page 10, lines 1-17) suitable stored 
in the data storage device (27 or 50) and configurable for use with the markup 
language rendering engine (page 8, lines 3-8), the markup language (page 9, lines 
8-13 and page 10, lines 1-17) being capable of soliciting at least one user input 
(see 210 and shown through 104, 1 10, and 112) when rendered (208) by the 
markup language rendering engine (page 8, lines 3-8) onto the display device (47), 
the user input (see 210 and shown through 104, 110, and 112) being associated 
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with a user logon process (210, 212, and 214) configured to selectively allow 
(214) a user to logon to the computer (20). 

Claim 22 recites a method for use in booting a computer (20) and logging 
users onto the computer (20), the method comprising, prior to allowing a user to 
logon (214) to a computer (20), loading (204) a markup language rendering engine 
(page 8, lines 3-8) substantially near the beginning of an operating system (35) 
initialization procedure ("start" of Fig. 3 and 202), retrieving user data (206) from 
the operating system (35), rendering (208) markup language code (page 9, lines 8- 
13 and page 10, lines 1-17) associated with a logon screen (100) using at least a 
portion of the user data (retrieved at 206), collecting (210) at least one user input 
associated with the logon screen (100), and establishing a logon session if the user 
input (210) is valid (214). 

Claim 27 recites a markup language based logon user interface arrangement 
for use in logging users onto a computer (20), the user interface comprising: a 
logon screen (100) displayed while booting ("start" of Fig. 3 and 202) the 
computer (20) and prior to allowing a user to logon (214) to a computer (20), a 
user logon area (104) within the logon screen (100), the user logon area (104) 
visually identifying a plurality of users using text identifiers (110) and graphical 
identifiers (112), such that each text identifier (110) and graphical identifier (112) 
are selectable by the user through the user interface and upon selection by the user 
cause the user interface to prompt the user to input a password (see 208), and a 
single selectable shut down mechanism (108) graphically located within the logon 
screen (100) and configured to shut the computer (20) down when selected 
through the user interface by the user. 
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(6) Grounds of Rejection to be Reviewed on Appeal 

Claims 1-29 stand rejected under 35 U.S.C. § 103(a) as being obvious over 
U.S. Pat. No. 6,438,580 to Mears, et al. (hereinafter, "Mears") in view of U.S. Pat. 
No. 6,026,388 to Liddy, et al. (hereinafter, "Liddy"). 

(7) Argument 

Claims 1-29 stand rejected under 35 U.S.C. § 103(a) as being obvious over 
Mears in view of Liddy. 

Claims 1-7 

Claim 1 

Appellant respectftiUy submits that the Examiner fails to establish a prima 
facie case of obviousness for rejecting Claim 1 in the Final Office Action. The 
Examiner fails to do so first by improperly equating a "user registration" of Mears 
with a logon process. Second, the Examiner fails to establish a prima facie case 
by not providing a legally sufficient basis for combining Liddy with Mears. For 
the reader's convenience, the subject matter of Claim 1 is provided below, after 
which Appellant submits its arguments for Claim 1 . 

Claim 1 recites a method for use in a computer, the method comprising: 

• while booting a computer and prior to allowing a user to logon to the 
computer, arranging for a markup language rendering engine to be 
loaded substantially near the beginning of an operating system 
initialization procedure; and 

• providing markup language code suitable for use with the markup 
language rendering engine, the markup language being capable of 
soliciting at least one user input when rendered by the markup 
language rendering engine, the user input being associated with a 
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user logon process configured to selectively allow a user to logon 
to the computer. 

The User Registration of Mears 

Appellant respectfully submits that the Examiner has failed to establish a 
prima facie case by improperly equating a "user registration" of Mears with a 
logon process. Appellant submits that Mears generally teaches against equating its 
"user registration" with a logon process because Mears assumes that a person 
using its "user registration" is already logged on. Appellant also submits, more 
specifically, that the Examiner's cited basis in Mears does not establish sufficient 
basis under 103 for equating the user registration of Mears to a logon process. 

Mears teaches against equating its "user registration" with a logon process 
by assuming that the user is already logged on. First, Mears discloses that the user 
is operating the computer before the user is enabled to use its "user registration". 
Second, Mears assumes that the user's identity is known before the user is enabled 
to use its "user registration". A user that is already operating a computer where 
the computer knows the user's identity is either logged on or, at the least, does not 
need to logon to the computer. 

First, Mears teaches that the user is operating the computer before the user 
is enabled to use its "user registration". Mears, at column 5, lines 60-67, teaches 
that a user is on a client computer running a web browser after which the user can 
select from categories listed in the web browser and then the web browser sends a 
request to a web page builder and server program. The web page builder and 
server program then locates the appropriate informational items, builds a web 
page, and sends it to the web browser for display. This action by the web page 
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builder and server program occurs after the user is already operating a computer 
but before the "user registration'" equated by the Examiner with the claimed logon 
process. 

Second, Mears assumes that the user's identity is known before the user is 
enabled to use its "user registration". The web page through which the 
Examiner's relied-on "user registration" may be selected provides options that 
must already know the identity of the user. At column 7, lines 14-16, Mears 
states: "Selecting favorite listing 162 displays a list of the users favorite or most 
useful areas of interactive knowledgebase 48". Mears assumes that the user's 
identity is known, otherwise, how could the favorite listing display a list of the 
user's favorite or most useful areas? At column 7, lines 43-49 (emphasis added), 
Mears states: 

Profile button 174 when selected brings up the user registration 
screens in the right window 1 54. User profile screens are used to set 
or modify user preferences. FIG. la illustrates a first registration 
screen 180. First registration screens 180 display current information 
regarding a user and allows a user to update that information. 

Mears teaches that the registration screens display current information about the 
user. To be current information about the user, the user's identity must be known. 
Also, how else could the user "update" his preferences if the computer does not 
already know the user's identity? 

For at least these reasons, Mears teaches generally against equating its 
^'user registration" with a logon process. Mears assumes that the user is already 
logged on, or, at the least, that the user is operating the computer and has his 
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identity known and so does not need to logon to the computer. Either way, Mears 
teaches away from equating Mears 's "user registration" with a logon process. 

The Examiner's argument that Mears 's user registration is patentably 
equivalent to the logon process completely ignores the context in which Mears's 
user registration is employed and ascribes properties to Mears's disclosure that it 
simply does not have. In addition, the Office's argument is akin to arguing that 
just because one disclosure is directed to enabling a user to input personal 
information that all other disclosures that present different, patentably distinct 
approaches for enabling a user to input personal information would be obvious. 

The Examiner's assertion that Mears's discussion of enabling a user to 
input his or her preferences implies the specific subject matter of this claim falls 
far short of the showing needed to establish a prima facie case of obviousness as 
required by the predecessor to the Federal Circuit. See, e.g., In re Royka, 490 F.2d 
981, 180 USPQ 580 (CCPA 1974) (the prior art reference or references when 
combined must teach or suggest all the claim limitations)(emphasis added). For at 
least this reason, Appellant respectfully submits that the Examiner has failed to 
establish a proper prima facie case of obviousness in the Final Office Action. 

Appellant also submits, more specifically, that the Examiner's cited basis in 
Mears does not establish sufficient basis under 103 for equating the user 
registration of Mears to a logon process. 

The Examiner, at page 3 of the Final Office Action, writes: "The Examiner 
asserts [that the] user registration of Mears (coL 7, lines 47-54) can also be a logon 
process because both the registration and logon process is where personal 
information is entered regarding the user to identify him/her to the computer." 
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Consider first the Examiner's citation in support of its assertion that 'Ihe user 
registration of Mears" can also be a "logon process'\ the entire!)* of which is set 
forth below: 

Profile button 174 when selected brings up the user registration screens in 
the right window 154. User profile screens are used to set or modify user 
preferences. FIG. 7a illustrates a first registration screen 180. First 
registration screens 180 display current information regarding a user and 
allows a user to update that information. Demographic profile section 182 
shows demographic information such as user name, phone numbers, 
Intemet mail address and other information. Profile information section 
184 contains a Ust of profile information entries for address 186, personal 
information 188, interests 190, roles 192 and notification 194, To the right 
of these entries is a status indicator 196 which indicates if the information 
entry has been completed or not. Each of the profile entries can be selected 
for updating and changing. This also allows a user to be associate with 
different database fields so that when the web page builder creates a web 
page regarding a certain category, individuals which are connected to that 
category by these entries can be included in the web page. 

Mears, col. 7, lines 44-62. 



The passage relied upon by the Examiner does not support the Examiner's 
assertion that "the user registration of Mears" can also be a "logon process". 
Instead, in this passage Mears discloses enabling a user to update his or her 
preferences. As described above, Mears's "user registration" is enabled only after 
the user has already logged in or, at the least, does not need to log in. Also, Mears 
uses the term "registration" is a manner inconsistent with a logon process. 

Mears's "user registration screens" on which the Examiner seems to rely, 
are generally equated by Mears with user profile screens. In the above passage 
Mears writes that these profile screens "are used to set or modify user 
preferences". (Mears, col. 7, lines 45-46). Thus, Mears generally equates the 
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''user registration screens" on which the Examiner seems to rely with enabling a 
user to set or modify his or her preferences rather than register the user. Also, 
when a user modifies a preference, the user is making a change to an existing 
preference associated with that user. A logon process does not enable a user to 
modify an existing preference associated with the user. In at least this sense, the 
"user registration screens" of Mears are not equivalent to a logon process. 

Mears also discloses specific examples of registration screens for a user to 
set or modify his or her preferences none of which suggest a logon process. Mears 
writes that the registration screens display current information regarding a user 
and allow a user to update that information in a knowledgebase. (Mears, col. 7-8). 
Mears continues, setting out in detail how his registration screens are used, writing 
that "an address registration screen 200" is one in which a "user can enter or 
change his address including street address, city, state/province, zip/postal code, 
country and primary language spoken." (Mears, col. 7, lines 63-67). Clearly, the 
registration screens of Mears are directed toward enabling a user to change his or 
her preferences — not logon to a computer. 

Not only does the passage cited by the Examiner not support the 
Examiner's assertion, Mears in total teaches against the Examiner's assertion. 

Insufficient Basis Given For Combining Mears and Liddy 

According to the Federal Circuit and the MPEP, the evidence on which an 
obviousness rejection is based must be set forth in the Office Action. MPEP 
2144.08 III states as follows: 
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Explicit findings on motivation or suggestion to select the claimed 
invention should also be articulated in order to support a 35 U.S.C. 103 
ground of rejection. Dillon, 919 F.2d at 693, 16 USPQ2d at 1901; In re 
Mills, 916 F.2d 680, 683, 16 USPQ2d 1430, 1433 (Fed. Cir. 1990), 
Conclusory statements of similarity or motivation, without any 
articulated rationale or evidentiary support, do not constitute factual 
findings. 

Further, according to the MPEP 2142 (emphasis added): 

The examiner bears the initial burden of factually supporting any prima 
facie conclusion of obviousness. If the examiner does not produce a 
prima facie case, the applicant is under no obligation to submit 
evidence of nonobviousness. 



Hence, when patentability turns on the question of obviousness, the search 
for and analysis of the prior art includes evidence relevant to the finding of 
whether there is a teaching, motivation, or suggestion to select and combine or 
modify the references relied on as evidence of obviousness. The need for 
specificity pervades this authority. See, e.g., In re Kotzab, 217 F.3d 1365, 1371, 55 
USPQ2d 1313, 1317 (Fed. Cir. 2000) ("particular findings must be made as to the 
reason the skilled artisan, with no knowledge of the claimed invention, would have 
selected these components for combination in the manner claimed"). 

Thus, the Examiner must provide factual evidence establishing 
nonobviousness rather than conclusory statements of motivation to establish a 
prima facie case of obviousness. 

The following comprises the Examiner's sole support for combining Mears 
and Liddy: 
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Although, Mears did teach the registration/logon process, 
Mears did not fully disclose to selectively allow a user to logon to a 
computer. 

Liddy, Et AL discloses the logon process in the form of a 
sign-on utilizing the GUI screen to allow users to interact with the 
system to select data resources, to create a natural language query, 
and to select criteria for retrieving and displaying documents. Liddy 
discusses that the GUI screen includes pull-down menus, a menu bar 
and various on screen windows for user inputs and interactions (coL 
27, lines 6-52). Further, Liddy teaches the selective sign-on process 
at the initial screen where only users with registered usemames and 
valid passwords are allowed access (col. 28, lines 41-50). 

Therefore, it would have been obvious for a person of 
ordinary skill in the art at the time of the invention to include 
selectively allow a user to logon to the computer would be for 
security purposes wherein only users that are registered that enters a 
registered usemame and valid password are allowed to proceed, 
(col. 28, lines 47-50). 

Final Office Action, pages 3-4, italics added for emphasis. 



The Examiner recorded a list of elements allegedly disclosed by Liddy and 
then concludes that "it would have been obvious ... to include [to] selectively 
allow a user to logon to the computer would be for security purposes". The 
Examiner recorded a list of elements and a conclusory motivation for combining 
Liddy with Mears — but did not provide evidence in support of that conclusion. 
The motivation "would be for security purposes" is too general to establish factual 
support. 

Appellant respectfully refers to the USPTO website for an article 
conceming formulating and communicating rejections under 35 U.S.C. 103 related 
to computer-implemented inventions. In this Article, the USPTO provides, in 
Section V, entitled "Examples of Improper Rejection under 35 U.S.C. 103", an 
exemplary improper rejection under 103 (italic emphasis added): 
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c. Poor statement of the rejection 

Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over 
Reference A in view of Reference B. Reference A discloses the 
conventional use of a smart card to track consumer preferences and 
provide incentives. However, Reference A does not disclose the 
automatic notification to consumer providing incentives. Reference B 
discloses providing incentives to consumers to purchase the desired 
products. It would have been obvious to combine Reference A's smart 
card with Reference B's incentive to consumers because the 
combination would allow Reference A 's smart card to be more efficient, 

d. Analysis 

The motivation, improve efficiency, is too general because it could 
cover almost any alteration contemplated of Reference A and does not 
address why this specific proposed modification would have been 
obvious. Additionally, there is nothing in either of [the] references that 
would suggest automatically notifying the consumer when reaching a 
threshold nor is there anything in either reference that would suggest the 
notifying step. Finally, although Reference B teaches a traditional 
coupon scheme to promote customer loyalty, there is no suggestion, 
other than applicant's disclosure, to employ this scheme to promote the 
introduction of new and altemative products. The rejection is 
improper. 

See www.uspto.gov/web/menu^usmethp/busmethl 03rej .htm#E 1 7 . 

It is telling that the USPTO considers the above-cited motivation — "to be 
more efficient" — given in support of the above exemplary rejection under 103 to 
be insufficient. Appellant considers the Examiner's stated motivation "would be 
for security purposes" to be similar to the motivation "to be more efficient" 
admonished by the USPTO. For at least this reason. Appellant respectfully 
submits that the Examiner failed to establish a prima facie case of obviousness. 

Also, Appellant submits that the Examiner failed to establish a prima facie 
case of obviousness by failing to establish a motivation to combine Mears with 
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Liddy sufficient to overcome Mears's teachings in contravention to a combination 
with Liddy. Mears teaches against combination with Liddy for the reasons stated 
above and in the "Summary of the Invention" section, where Mears writes that 
"[i]n accordance with the teachings of the present invention, an interactive 
knowledgebase is provided which substantially eliminates or reduces the 
disadvantages and problems associated with existing database structures." (Mears, 
at Summary of the Invention, col. 1, lines 39-44). The teachings of Mears are 
directed to that of an interactive knowledgebase that substantially eliminates or 
reduces the disadvantages and problems associated with existing database 
stmctures — not logging onto a computer. 

For this and other reasons set forth above, Mears 's disclosure is directed 
away from combination with Liddy. Yet the Examiner's argument in support of 
combining Liddy with Mears — that it would be obvious to combine them for 
security purposes — provides little if any factual support sufficient to contravene 
the teaching of Mears against this combination. 

Claims 2-7 

Claims 2-7 depend from Claim 1 and are allowable as depending from an 
allowable base claim. These claims are also allowable for their own recited 
features that, singly or in combination with those recited in Claim 1, have not been 
shown to be obvious in the Final Office Action. 
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Claims 8-14 

Claim 8 

Appellant respectfully submits that the Examiner fails to establish a prima 
facie case of obviousness for rejecting Claim 8 in the Final Office Action. The 
Examiner fails to do so first by improperly equating a "user registration" of Mears 
with a logon process. Second, the Examiner fails to estabhsh a prima facie case 
by not providing a legally sufficient basis for combining Liddy with Mears. For 
the reader's convenience, the subject matter of Claim 8 is provided below, after 
which Appellant submits its arguments for Claim 8. 

Claim 8 recites a computer-readable medium having computer-executable 
instructions for causing one or more processors to perform acts comprising: 

• while booting a computer and prior to allowing a user to logon to the 
computer, arranging for a markup language rendering engine to be 
loaded substantially near the beginning of an operating system 
initialization procedure; and 

• providing markup language code suitable for use with the markup 
language rendering engine, the markup language being capable of 
soliciting at least one user input when rendered by the markup 
language rendering engine, the user input being associated with a 
user logon process configured to selectively allow a user to logon 
to the computer. 

The Examiner's argument in support of her rejection of Claim 8 relies on 
the language and reasoning addressed in Appellant's argument set forth for Claim 
1 above. For any of the reasons set forth above, Appellant submits that the 
Examiner has failed to establish a prima facie case of obviousness in rejecting 
Claim 8. 
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Claims 9-14 

Claims 9-14 depend from Claim 8 and are allowable as depending from an 
allowable base claim. These claims are also allowable for their own recited 
features that, singly or in combination with those recited in Claim 8, have not been 
shown to be obvious in the Final Office Action. 

Claims 15-21 

Claim 15 

Appellant respectftilly submits that the Examiner fails to establish a prima 
facie case of obviousness for rejecting Claim 1 5 in the Final Office Action. The 
Examiner fails to do so first by improperly equating a "user registration" of Mears 
with a logon process. Second, the Examiner fails to establish a prima facie case 
by not providing a legally sufficient basis for combining Liddy with Mears. For 
the reader's convenience, the subject matter of Claim 15 is provided below, after 
which Appellant submits its arguments for Claim 15. 

Claim 1 5 recites an arrangement including a memory, a data storage device, 
a display device, and a processor operatively coupled to the memory, data storage 
device and the display device, the arrangement comprising: 

• a markup language rendering engine stored within the data storage 
device and suitable for loading in the memory substantially near the 
beginning of an operating system initialization procedure while 
booting a computer and prior to allowing a user to logon to the 
computer; and 

• markup language code suitable stored in the data storage device and 
configurable for use with the markup language rendering engine, the 
markup language being capable of soliciting at least one user input 
when rendered by the markup language rendering engine onto the 
display device, the user input being associated with a user logon 
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process configured to selectively allow a user to logon to the 
computer. 

The Examiner's argument in support of her rejection of Claim 15 relies on 
the language and reasoning addressed in Appellant's argument set forth for Claim 
1 above. For any of the reasons set forth above, Appellant submits that the 
Examiner has failed to establish a prima facie case of obviousness in rejecting 
Claim 15. 

Claims 16-21 

Claims 16-21 depend from Claim 15 and are allowable as depending from 
an allowable base claim. These claims are also allowable for their own recited 
features that, singly or in combination with those recited in Claim 15, have not 
been shown to be obvious in the Final Office Action. 

Claims 22-26 

Claim 22 

Appellant respectfully submits that the Examiner fails to establish a prima 
facie case of obviousness in rejecting Claim 22. First, the Examiner fails to 
establish a prima facie case by failing to show that the cited references disclose an 
element of Claim 22. Second, the Examiner fails to establish a prima facie case 
by not providing a legally sufficient basis for combining Liddy with Mears. For 
the reader's convenience, the subject matter of Claim 22 is provided below, after 
which Appellant submits its arguments for Claim 22. 
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Claim 22 recites a method for use in booting a computer and logging users 
onto the computer, the method comprising: 

• prior to allowing a user to logon to a computer, loading a markup 
language rendering engine substantially near the beginning of an 
operating system initialization procedure; 

• retrieving user data from the operating system; 

• rendering markup language code associated with a logon screen 
using at least a portion of the user data; 

• collecting at least one user input associated with the logon screen; 
and 

• establishing a logon session if the user input is valid. 

Elements of Claim 22 

First, the Examiner fails to show that the cited references disclose an 
element of Claim 22. At page 1 1 of the Final Office Action, the Examiner asserts 
that Mears discloses a logon screen, writing: "[CJollecting at least one user input 
associated with the logon screen; and (col. 7, lines 50-51)." Consider first the 
Examiner's citation in support of its assertion that Mears discloses collecting at 
least one user input associated with the logon screen, the entirety of which is set 
forth and underlined within the quotation below: 

Profile button 1 74 when selected brings up the user registration screens in 
the right window 154. User profile screens are used to set or modify user 
preferences. FIG. 7a illustrates a first registration screen 180. First 
registration screens 1 80 display current information regarding a user and 
allows a user to update that information. Demographic profile section 1 82 
shows demographic information such as user name, phone numbers, 
Internet mail address and other information. Profile information section 
184 contains a list of profile information entries for address 186, personal 
information 188, interests 190, roles 192 and notification 194. To the right 
of these entries is a status indicator 196 which indicates if the information 
entry has been completed or not. Each of the profile entries can be selected 
for updating and changing. This also allows a user to be associate with 
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different database fields so that when the web page builder creates a web 
page regarding a certain category, individuals which are connected to that 
category by these entries can be included in the web page. 

Mears, coL 7, lines 44-62 (emphasis added). 

This passage of Mears do not disclose, teach, or imply a logon screen as 
required by Claim 22, So far as might be deemed relevant to the presently claimed 
subject matter, in this passage Mears simply discloses enabling a user to update his 
or her preferences through a screen displaying current information. 

This passage, like some of those discussed in the argument for Claim 1, are 
directed to enabling a user to update his or her preferences, which assumes that a 
user is already logged on or does not need to do so. For at least this reason, the 
cited passage does not disclose, teach, or imply a logon screen as required by 
Claim 22. 

Also in this passage, Mears equates registration screens generally with user 
profile screens. Mears writes that these user profile screens "are used to set or 
modify user preferences". Thus, Mears teaches that his registration screens are 
generally for receiving input to set and modify a user's preferences rather than 
logon to a computer. 

Further, Mears discloses specific examples of registration screens that are 
for a user to set or modify user preferences having nothing to do with logging onto 
a computer. Mears writes that the registration screens display current information 
regarding a user and allow a user to update that information in a knowledgebase. 
(Mears, col. 7-8). Mears continues, setting out how his registration screens are 
used in detail, writing that "an address registration screen 200" is one in which a 
"user can enter or change his address including street address, city, state/province, 
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zip/postal code, country and primary language spoken." (Mears, col. 7, lines 63- 
67). Clearly, the registration screens of Mears are directed toward enabling a user 
to change his or her preferences. 

Thus, Mears teaches that his disclosed invention, and its operation through 
registration screens, is directed to enabling a user to add or edit content for setting 
and modifying preferences. Setting and modifying preferences is not equivalent to 
collecting at least one user input associated with a logon screen. Thus, on its face, 
the Examiner's support for showing that "collecting at least one user input 
associated with the logon screen" is not shown in Mears. The Examiner does not 
argue that Liddy discloses this element. For at least this reason, the rejection of 
Claim 22 under 103 has not been proved by the Examiner. 

Not only does the passage cited by the Examiner not support the 
Examiner's assertion, Mears generally teaches against the Examiner's assertion. 
Appellant refers the reader to the argument with respect to Claim 1 . 

Insufficient Basis Given For Combining Mears and Liddy 

Similarly to the Examiner's language in rejecting Claim 1 above, the 

Examiner provides insufficient factual support for combining Mears and Liddy. 

The Examiner instead relies on a conclusory statement of motivation to establish 

its case of obviousness. 

The following comprises the Examiner's sole support for combining Mears 

and Liddy in rejecting Claim 22: 

Although, Mears did teach the user input associated with the 
registration/logon screen, Mears did not fully disclose establishing a 
logon session if the user input is valid. 
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Liddy, Et Al. discloses the logon process in the form of a 
sign-on utilizing the GUI screen to allow users to interact with the 
system to select data resources^ to create a natural language query, 
and to select criteria for retrieving and displaying documents. Liddy 
discusses that the GUI screen includes pull-down menus, a menu bar 
and various on screen windows for user inputs and interactions (col. 
27, lines 6-52). Further, Liddy teaches the sign-on process at the 
initial screen establishing a logon session if the user input is valid 
(col. 28, lines 48-50). 

It would have been obvious for a person of ordinary skill in 
the art at the time of the invention establishing a logon session if the 
user input is valid as taught in Liddy, would be for security purposes 
wherein only users that are registered that enters a registered 
usemame and valid password are allowed to proceed (col. 28, lines 
44-50). 

Final Office Action, pages 11-12, italics added for emphasis. 



The Examiner concludes, but does not provide evidence in support of that 
conclusion. The motivation "would be for security purposes" is too general to 
establish factual support, as is argued above in regard to Claim 1 . For at least this 
reason, Appellant respectfully submits that the Examiner failed to establish a 
prima facie case of obviousness in rejecting Claim 22. 



Claims 23-26 

Claims 23-26 depend from Claim 22 and are allowable as depending from 
an allowable base claim. These claims are also allowable for their own recited 
features that, singly or in combination with those recited in Claim 22, have not 
been shown to be obvious in the Final Office Action, 
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Claims 27-29 

Claim 27 

Appellant respectflilly submits that the Examiner fails to establish a prima 
facie case of obviousness for rejecting Claim 27 in the Final Office Action. The 
Examiner fails to do so first by failing to show that the cited references discloses 
elements of Claim 27. Second, the Examiner fails to establish a prima facie case 
by improperly equating a "user registration" of Mears with a logon screen. Third, 
the Examiner fails by not providing a legally sufficient basis for combining Liddy 
with Mears. Fourth, the Examiner has not provided references establishing an 
asserted inherency and obviousness in rejecting Claim 27. For the reader's 
convenience, the subject matter of Claim 27 is provided below, after which 
Appellant submits its arguments for Claim 27. 

Claim 27 recites a markup language based logon user interface arrangement 
for use in logging users onto a computer, the user interface comprising: 

• a logon screen displayed while booting the computer and prior to 
allowing a user to logon to a computer; 

• a user logon area within the logon screen, the user logon area 
visually identifying a plurality of users using text identifiers and 
graphical identifiers, such that each text identifier and graphical 
identifier are selectable by the user through the user interface and 
upon selection by the user cause the user interface to prompt the user 
to input a password; and 

• a single selectable shut down mechanism graphically located within 
the logon screen and configured to shut the computer down when 
selected through the user interface by the user. 
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Cited References Not Shown To Teach All Elements of Claim 27 

First, the Examiner fails to establish a prima facie case of obviousness by 
failing to show that the cited references disclose all elements of Claim 27. In 
making out the rejection of this claim, the Examiner argues the Mears reference 
and uses language that does not appear in this claim. For example, the Examiner 
argues that Mears discloses "a logon screen displayed while booting the computer 
and prior to allowing a user to logon to a computer" and cites to column 4, lines 
11-35 for support. (Final Office Action, p. 13). Also for example, the Examiner 
argues that Mears discloses "a user logon area within the logon screen" and cites 
to column 7, lines 42-47 for support. (/J.). Also for example, the Examiner 
argues that Mears discloses "the user logon area visually identifying a plurality of 
users using text identifiers and graphical identifiers, such that each text identifier 
and graphical identifier are selectable by the user through the user interface" and 
cites to column 7, lines 57-59 for support. {Id,), None of the text cited above for 
support by the Examiner disclose the language appearing in Claim 27. To the 
extent that the terminology utilized by the Examiner in making out this rejection 
varies from the specific claim language that appears in this claim, Appellant 
respectfully submits that the Examiner has improperly addressed the claim. 
Nowhere does Mears disclose, suggest, or imply the claimed elements of a logon 
screen displayed while booting the computer or a user logon area within the logon 
screen, as required in Claim 27. Mears discloses enabling input of user 
preferences; it does not disclose any of these claimed elements. Appellant 
respectfully submits that the Examiner misuses Mears in rejecting Claim 27. 
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The User Registration of Mears 

Second, the Examiner fails to establish a prima facie case by improperly 
equating a "user registration'' of Mears with a logon screen. The Examiner asserts 
that: "user registration of Mears (col. 7, lines 47-54) can also be a logon process 
because both the registration and logon process is where personal information is 
entered regarding the user to identify him/her to access the computer." (Final 
Office Action, p. 14). The Examiner's argument in support of her rejection of 
Claim 27 relies on reasoning addressed in Appellant's argument set forth for 
Claim 1 above. For any of the reasons set forth for Claim 1, Appellant submits 
that the Examiner has failed to establish a prima facie case of obviousness in 
rejecting Claim 27. 

Insufficient Basis Given For Combining Mears and Liddy 

Third, the Examiner fails by not providing a legally sufficient basis for 
combining Liddy with Mears. As set forth in Appellant's argument above in 
regard to Claim 1 , the Examiner fails to provide a sufficient suggestion or 
motivation for combining Mears with Liddy, thereby failing to establish a prima 
facie case of obviousness. 

Failure to Establish Asserted Inherency 

Fourth, the Examiner has failed to provide references establishing an 
asserted inherency and obviousness in attempting to show disclosure of an element 
of Claim 27. The Examiner admits that "Mears did not fully disclose prompting 
the user to input a password and a single selectable shut down mechanism 
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configured to shut the computer down when selected through the user interface by 
the user'\ (Final Office Action, p. 14). To address this deficiency, the Examiner 
writes that "[i]t is inherent that computers have a shut down mechanism option 
placed on a window for a user to select when wanting to shut the computer off. 
The Examiner ascertains the shut down option and the logon option is amongst the 
various functions if an appropriate command is selected on the screen." (Id,), 

The Examiner has not provided references establishing the asserted 
inherency and obviousness, and as such has failed to establish a prima facie case 
of obviousness under §103. 

On any one of these grounds, the Examiner's argument in the Final Office 
Action fails to establish a prima facie case of obviousness under §103 in rejecting 
Claim 27. 

Claims 28-29 

Claims 28-29 depend from Claim 27 and are allowable as depending from 
an allowable base claim. These claims are also allowable for their own recited 
features that, singly or in combination with those recited in Claim 27, have not 
been shown to be obvious in the Final Office Action. 
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Conclusion 

Appellant respectfiilly submits that all of the Examiner's rejections have 
been traversed. As such, Appellant respectfully submits that all of the claims are 
in condition for allowance. 



Respectfully Submitted, 



Dated: 

hid OS ^'L^^\/ 

Michael K. Colby 
Lee & Hayes, PLLC 
Reg. No. 45,816 
(509) 324-9256 ext. 240 
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(8) Appendix of Appealed Claims 

1. (previously presented) A method for use in a computer, the method 
comprising: 

while booting a computer and prior to allowing a user to logon to the 
computer, arranging for a markup language rendering engine to be loaded 
substantially near the beginning of an operating system initialization procedure; 
and 

providing markup language code suitable for use with the markup language 
rendering engine, the markup language being capable of soliciting at least one user 
input when rendered by the markup language rendering engine, the user input 
being associated with a user logon process configured to selectively allow a user 
to logon to the computer. 

2. (original) The method as recited in Claim 1, wherein providing the 
markup language code further includes providing user data, the user data being 
operatively associated with the user logon process. 

3. (original) The method as recited in Claim 2, wherein the user data 
includes data selected from a set comprising a list of users, a text identifier, a 
graphical identifier, a password enabled identifier, and password hint data, and 
related user information data. 
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4. (original) The method as recited in Claim 2, further comprising: 

configuring the markup language rendering engine to display at least a 
portion of the user data based on the markup language code. 

5. (original) The method as recited in Claim 1, further comprising: 
configuring the markup language code to provide the user input to an 

authorization entity for validation determination. 

6. (original) The method as recited in Claim 1, wherein the user input 
includes at least one input selected from a group of inputs comprising a user name, 
a user identifier, and a password. 

7. (original) The method as recited in Claim 1, wherein the markup 
language code includes markup language code selected from at least one markup 
language in a group comprising hypertext markup language (HTML), Dynamic 
Hypertext Markup Language (DHTML), extensible Markup Language (XML), 
extensible Hypertext Markup Language (XHTML), and Standard Generalized 
Markup Language (SGML). 
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8. (previously presented) A computer-readable medium having computer- 
executable instructions for causing one or more processors to perform acts 
comprising: 

while booting a computer and prior to allowing a user to logon to the 
computer, arranging for a markup language rendering engine to be loaded 
substantially near the beginning of an operating system initialization procedure; 
and 

providing markup language code suitable for use with the markup language 
rendering engine, the markup language being capable of soliciting at least one user 
input when rendered by the markup language rendering engine, the user input 
being associated with a user logon process configured to selectively allow a user 
to logon to the computer. 

9. (original) The computer-readable medium as recited in Claim 8, 
wherein providing the markup language code further includes providing user data, 
the user data being operatively associated with the user logon process. 

10. (original) The computer-readable medium as recited in Claim 9, 
wherein the user data includes data selected from a set comprising a list of users, a 
text identifier, a graphical identifier, a password enabled identifier, and password 
hint data, and related user information data. 
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1 1 . (previously presented) The computer-readable medium as recited in 
Claim 9, having further computer-executable instructions for performing acts 
comprising: 

configuring the markup language rendering engine to display at least a 
portion of the user data based on the markup language code. 

12. (previously presented) The computer-readable medium as recited in 
Claim 8, having further computer-executable instructions for performing acts 
comprising: 

configuring the markup language code to provide the user input to an 
authorization entity for validation determination. 

13. (original) The computer-readable medium as recited in Claim 8, 
wherein the user input includes at least one input selected from a group of inputs 
comprising a user name, a user identifier, and a password. 

14. (original) The computer-readable medium as recited in Claim 8, 
wherein the markup language code includes markup language code selected from 
at least one markup language in a group comprising hypertext markup language 
(HTML), Dynamic Hypertext Markup Language (DHTML), extensible Markup 
Language (XML), extensible Hypertext Markup Language (XHTML), and 
Standard Generalized Markup Language (SGML). 
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15. (previously presented) An arrangement including a memory, a data 
storage device, a display device, and a processor operatively coupled to the 
memory, data storage device and the display device, the arrangement comprising: 

a markup language rendering engine stored within the data storage device 
and suitable for loading in the memory substantially near the beginning of an 
operating system initialization procedure while booting a computer and prior to 
allowing a user to logon to the computer; and 

markup language code suitable stored in the data storage device and 
configurable for use with the markup language rendering engine, the markup 
language being capable of soliciting at least one user input when rendered by the 
markup language rendering engine onto the display device, the user input being 
associated with a user logon process configured to selectively allow a user to 
logon to the computer. 

16. (original) The arrangement as recited in Claim 15, further comprising 
user data stored in the data storage device and configurable for use with the 
markup language rendering engine, the user data being operatively associated with 
the user logon process. 

17. (original) The arrangement as recited in Claim 16, wherein the user 
data includes data selected from a set comprising a list of users, a text identifier, a 
graphical identifier, a password enabled identifier, and password hint data, and 
related user information data. 
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18. (original) The arrangement as recited in Claim 16, wherein the markup 
language rendering engine is further configurable to display at least a portion of 
the user data on the display device based on the markup language code. 

19. (original) The arrangement as recited in Claim 15, further comprising 
an authorization entity stored within the data storage device, and wherein the 
markup language rendering engine is further configurable to provide the user input 
to the authorization entity for validation determination based on the markup 
language code. 

20. (original) The arrangement as recited in Claim 15, wherein the user 
input includes at least one input selected from a group of inputs comprising a user 
name, a user identifier, and a password. 

21. (original) The arrangement as recited in Claim 15, wherein the markup 
language code includes markup language code selected from at least one markup 
language in a group comprising hypertext markup language (HTML), Dynamic 
Hypertext Markup Language (DHTML), extensible Markup Language (XML), 
extensible Hypertext Markup Language (XHTML), and Standard Generalized 
Markup Language (SGML). 
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22. (previously presented) A method for use in booting a computer and 
logging users onto the computer, the method comprising: 

prior to allowing a user to logon to a computer, loading a markup language 
rendering engine substantially near the beginning of an operating system 
initialization procedure; 

retrieving user data from the operating system; 

rendering markup language code associated with a logon screen using at 
least a portion of the user data; 

collecting at least one user input associated with the logon screen; and 
establishing a logon session if the user input is valid. 

23. (original) A method as recited in Claim 22 wherein establishing a 
logon session further includes: 

providing the user input to the operating system; and 
causing the operating system to authenticate the user input. 

24. (original) The method as recited in Claim 23, wherein establishing a 
logon session further includes providing the user input to an authorization entity 
for validation determination. 

25. (original) The method as recited in Claim 22, wherein the user data 
includes data selected from a set comprising a list of users, a text identifier, a 
graphical identifier, a password enabled identifier, and password hint data, and 
related user information data. 
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26. (original) The method as recited in Claim 22, wherein the markup 
language code includes markup language code selected from at least one markup 
language in a group comprising hypertext markup language (HTML), Dynamic 
Hypertext Markup Language (DHTML), extensible Markup Language (XML), 
extensible Hypertext Markup Language (XHTML), and Standard Generalized 
Markup Language (SGML). 

27. (previously presented) A markup language based logon user interface 
arrangement for use in logging users onto a computer, the user interface 
comprising: 

a logon screen displayed while booting the computer and prior to allowing 
a user to logon to a computer; 

a user logon area within the logon screen, the user logon area visually 
identifying a plurality of users using text identifiers and graphical identifiers, such 
that each text identifier and graphical identifier are selectable by the user through 
the user interface and upon selection by the user cause the user interface to prompt 
the user to input a password; and 

a single selectable shut down mechanism graphically located within the 
logon screen and configured to shut the computer down when selected through the 
user interface by the user. 

28. (original) The user interface as recited in Claim 27, wherein the logon 
screen is rendered substantially near the beginning of the initialization of the 
operating system using a markup language rendering engine. 
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29. (original) The user interface as recited in Claim 28, wherein the logon 
screen is rendered during using markup language code selected from at least one 
markup language in a group comprising hypertext markup language (HTML), 
Dynamic Hypertext Markup Language (DHTML), extensible Markup Language 
(XML), extensible Hypertext Markup Language (XHTML), and Standard 
Generalized Markup Language (SGML). 



37 



Application No. oy, 539,231 



